| Fuente | Registros |
|---|---|
| OBIS | 46848 |
| GBIF | 0 |
| Combinados | 46848 |
| Limpios | 249 |
1 Introducción
La biodiversidad marina enfrenta amenazas sin precedentes debido al cambio climático, la acidificación oceánica, y las actividades antropogénicas. Este análisis utiliza un pipeline integrado que combina múltiples fuentes de datos y métodos analíticos avanzados para evaluar el estado de conservación y los patrones evolutivos de especies marinas clave.
La robustez metodológica es tan importante como los resultados mismos, especialmente en campos como la biología de la conservación y la evolución, donde las decisiones pueden tener implicaciones a largo plazo y deben basarse en evidencia auditable y reproducible.
1.1 Ciencias Multiómicas
Multiómicos se refiere a un enfoque de investigación que integra datos de múltiples disciplinas “ómicas” (como la genómica, proteómica, transcriptómica, etc.) para obtener una comprensión más completa y holística de un sistema biológico, enfermedad o proceso celular. Al combinar estos diferentes niveles moleculares, los estudios multiómicos permiten inferir mecanismos biológicos subyacentes de manera más precisa, desentrañar las causas de fenómenos complejos y descubrir biomarcadores.
Ómicas clave que se integran:
- Genómica: Estudio de los genes y su variación.
- Transcriptómica: Estudio de los ARN mensajeros (ARNm) para entender la expresión génica.
- Proteómica: Estudio de las proteínas, sus estructuras y funciones.
- Metabolómica: Estudio de los metabolitos y cómo interactúan.
- Epigenómica: Estudio de los cambios heredables en la expresión génica sin alterar la secuencia de ADN.
- Microbioma: Estudio de las comunidades microbianas y su impacto en el huésped.
1.2 El Paradigma de la Investigación Reproducible
Establecer el marco conceptual y la necesidad urgente de la reproducibilidad computacional en las ciencias, particularmente en ecología y evolución.
(Noble 2009): The core guiding principle is simple: Someone unfamiliar with your project should be able to look at your computer files and understand in detail what you did and why. This ‘‘someone’’ could be any.
(Dolstra 2006): The development of principles and tools to support the deployment process has largely been relegated to industry, system administrators, and Unix hackers. This has resulted in a large number of often ad hoc tools that typically automate manual practices but do not address fundamental issues in a systematic and disciplined way. This is evidenced by the huge number of mailing list and forum postings about deployment failures, ranging from applications not working due to missing dependencies, to subtle malfunctions caused by incompatible components. Deployment problems also seem curiously resistant to automation: the same concrete problems appear time and again. Deployment is especially difficult in heavily component-based systems—such as Unix-based open source software—because the effort of dealing with the dependencies can increase super-linearly with each additional dependency. This work describes a system for software deployment called Nix (trough ‘{rix}-r package’) that addresses many of the problems that plague existing deployment systems.
(Wilson et al. 2017): Este artículo Justifica la necesidad de prácticas como la automatización de flujos de trabajo (e este proyecto usamos herramientas como Make y {targets}) y el seguimiento de versiones del software (lo que logra con Nix). Argumentar que su metodología no es una complejidad innecesaria, sino una adhesión a las “buenas prácticas” recomendadas por la comunidad científica para evitar errores y asegurar la longevidad de los resultados.
(Marwick, Boettiger, y Mullen 2018): Este artículo aborda directamente el ecosistema de R. Explica cómo empaquetar un proyecto de análisis de datos (código, datos y el ambiente computacional) para hacerlo reproducible. Proporciona el argumento académico perfecto para justificar por qué usar una herramienta como Nix (a través de rix) es una solución superior a simplemente listar los paquetes, ya que captura el estado completo del sistema.
1.3 Gestión del Ambiente Computacional con Nix
Estas referencias validan el uso de gestores de ambientes declarativos como Nix para garantizar la reproducibilidad a nivel de software.
(Dolstra 2006): Esta es la fuente original que describe el modelo detrás de Nix. Es una referencia más técnica, pero citarla demuestra un profundo entendimiento de los fundamentos de su flujo de trabajo. Puede usarla para afirmar que su proyecto se basa en un “modelo puramente funcional” que garantiza la construcción de ambientes computacionales determinísticos, eliminando problemas comunes como el “funciona en mi máquina”.
Abogar por herramientas como Nix para resolver la “crisis de reproducibilidad” en campos computacionalmente intensivos. Citar este artículo le permite establecer un paralelismo, argumentando que, al igual que en la neurociencia, la complejidad del análisis de datos genómicos, espaciales y taxonómicos en la conservación marina exige soluciones de reproducibilidad robustas.
1.3.1 Manejo de ambientes: Nix vs otras opciones
Utilizar ‘Nix’ mediante el paquete ‘rix’ es una opción más robusta para gestionar entornos científicos y pipelines frente a herramientas como ‘conda’ o ‘renv’. Se incluye una tabla comparativa seguida de una breve recomendación de uso.
| Criterio / Aspecto | Nix (con rix) | Conda | renv |
|---|---|---|---|
| Reproducibilidad determinista | Muy alta. Nix es declarativo e inmune a cambios del sistema; rix genera expresiones reproducibles para R y deps del sistema. | Moderada. Conda puede registrar versiones, pero la resolución de dependencias y canales introduce variabilidad. | Parcial. Fija versiones de paquetes R (lockfile) pero no gestiona dependencias del sistema nativas. |
| Gestión de dependencias del sistema (C, libs, binarios) | Nativa y exhaustiva. Nix declara y proporciona librerías del sistema de forma aislada. | Buena (conda-forge), pero limitada para ciertos paquetes del sistema y con problemas de enlaces dinámicos. | Ninguna. Depende del SO o de gestores externos; riesgo de “works on my machine”. |
| Aislamiento / hermeticidad | Alto: entornos aislados en la store de Nix; evita contaminación por el entorno del usuario. | Aislado a nivel de entorno, pero puede verse afectado por bibliotecas del sistema; problemas con PATH/LD_LIBRARY_PATH. | No a nivel de sistema; sólo controla paquetes R dentro del proyecto. |
| Declaratividad y trazabilidad | Declarativo (nix expressions). Fácil de versionar, auditar y reconstruir. | Declarativo limitado (environment.yml), pero resolución no determinista entre ejecuciones. | Declarativo para R (renv.lock) pero sin trazabilidad de libs externas. |
| Integración con CI / archivado a largo plazo | Excelente: reconstrucción reproducible en CI; uso de cachés binarios; apto para archivado y publicación de entornos. | Buena en CI, pero reproducibilidad exacta depende de canales y binarios disponibles. | Adecuado para reproducir entornos R en el corto/medio plazo; falla si faltan deps del sistema. |
| Compatibilidad multi-lenguaje | Sí, gestiona todo el stack (R, Python, C, system tools) en un único lenguaje de especificación. | Buena (R, Python, otros), pero fragmentación en canales. | Enfocado a R; no gestiona otros lenguajes de forma integrada. |
| Facilidad de uso / curva de aprendizaje | Moderada a alta. rix reduce la barrera para usuarios de R pero Nix tiene conceptos nuevos. | Baja (fácil de empezar). Muy accesible para usuarios nuevos. | Muy baja — transparente para usuarios R; fácil de incorporar. |
| Tamaño / consumo de disco | Amplio (store de Nix), pero con beneficios de caché y deduplicación entre proyectos. | Variable; entornos duplicados pueden consumir mucho. | Ligero (solo paquetes R), pero requiere deps del sistema por separado. |
| Limitaciones notables | Curva de aprendizaje; en Windows requiere WSL o soluciones; rix aún evoluciona. | Canales y resolución crean incoherencias; algunos paquetes de sistema difíciles. | No asegura reproducibilidad completa (falta libs del SO); no declara sistema. |
| Uso recomendado | Pipelines reproducibles, CI/archivado, proyectos con dependencias R + sistema, entornos multi-lenguaje y producción. | Entornos ad-hoc, exploración rápida, usuarios que necesitan rápidos “envs” multiplataforma. | Desarrollo R colaborativo rápido, lockfiles para paquetes R, proyectos que delegan deps del SO a otra solución. |
Tip
Uso de ‘conda’ + ‘Nix’ (‘{rix}’)
- Es posible usar conda dentro de un entorno generado con ‘rix/Nix’: ‘Nix’ puede instalar paquetes del ecosistema ‘conda’ (p. ej. ‘miniconda3’) y ejecutar comandos conda desde el ‘shell’ que ‘Nix’ provee. ‘rix’, al final, genera expresiones ‘Nix’; en esas expresiones se pueden declarar paquetes del sistema como “‘miniconda3’” o “‘mamba’” y añadir un ‘shell_hook’ para crear/activar un entorno conda/‘conda-env’ al entrar al ‘nix-shell’.
- Sin embargo, en términos de reproducibilidad y coherencia, incluir ‘conda’ dentro de ‘Nix’ es en gran medida redundante y atenta contra las garantías que ‘Nix’ aporta: ‘conda’ genera entornos que no son \(100\%\) declarativos ni bit-reproducibles (resolución de dependencias y artefactos binarios dependen de servidores externos). Por ello, el patrón recomendado es gestionar ‘Python’ y sus binarios desde ‘Nix’ (‘nixpkgs’) siempre que sea posible; solo recurrir a conda cuando exista una dependencia binaria crítica que no esté disponible en ‘nixpkgs’ o cuando el equipo ya dependa fuertemente de ‘conda’ y se acepte la pérdida parcial de determinismo.
Gestión de dependencias del sistema
- ‘rix/Nix’ gestiona paquetes de sistema (‘git’, ‘libssl’, binarios ‘C/Fortran’) de forma nativa y declarativa. ‘Conda’ (especialmente ‘conda-forge’) puede proveer muchos paquetes binarios (‘python’, librerías científicas), pero no sustituye a un gestor de sistema para librerías del sistema (p. ej. ‘glibc’, versiones del compilador) y su resolución depende de canales; por tanto, no iguala la hermeticidad ni la trazabilidad de ‘Nix’.
Recomendaciones prácticas y consideraciones
- Preferible: declarar ‘Python’ y paquetes ‘Python’ directamente en ‘Nix’ (usar paquetes ‘python’ de ‘nixpkgs’ o ‘poetry2nix/pypi2nix’), o usar ‘mamba/conda’ dentro de ‘Nix’ solo para casos puntuales.
- Ventaja: entornos completamente reconstruibles en ‘CI’ y archivables con la expresión ‘Nix’.
- Si se incorpora ‘conda’ dentro de ‘Nix’: incluir ‘miniconda/mamba’ como ‘system_pkgs’ en ‘rix()’ y ‘use shell_hook’ para crear/activar un entorno ‘conda’ desde un ‘environment.yml’ almacenado en el repositorio. Documentar explícitamente este paso y aceptar las limitaciones de determinismo.
- ‘Conda’ puede instalar muchos paquetes “del sistema” (a través de ‘conda-forge’), pero no gestiona el sistema base ni garantiza identicidad binaria entre máquinas; ‘Nix’ sí lo hace.
Ejemplo práctico
— modificación sugerida de’ build_env.R’ (opcional: integrar ‘conda/miniconda’ y crear env al entrar al ‘nix-shell’):
# ...existing code...
rix(
r_ver = "latest-upstream",
r_pkgs = all_packages,
- system_pkgs = c("git", "python3", "quarto"),
+ # Incluir miniconda3 si se necesita usar conda dentro del entorno Nix.
+ # Alternativa recomendada: gestionar Python desde nixpkgs (evita redundancia).
+ system_pkgs = c("git", "python3", "quarto", "miniconda3"),
- tex_pkgs = c("amsmath"),
- ide = "none",
- shell_hook = "",
+ tex_pkgs = c("amsmath"),
+ ide = "none",
+ # Ejemplo de shell_hook que crea/actualiza un entorno conda local a partir de environment.yml.
+ # Nota: esto ejecuta conda al entrar al nix-shell; la reproducibilidad del entorno conda
+ # depende de conda/mamba y de los canales usados.
+ shell_hook = '
+if [ -f environment.yml ]; then
+ if [ ! -d ".conda-env" ]; then
+ echo "Creando entorno conda local (.conda-env) desde environment.yml..."
+ conda env create -p ./.conda-env -f environment.yml || conda env update -p ./.conda-env -f environment.yml
+ fi
+ export PATH="$(pwd)/.conda-env/bin:$PATH"
+fi
+',
project_path = ".",
overwrite = TRUE,
print = TRUE
)
# ...existing code...Caveats técnicos y cierre
- Mezclar ‘Nix + conda’ es factible pero introduce una capa menos declarativa (‘conda’). Para reproducibilidad académica estricta, preferir ‘Nix-native’ (‘nixpkgs/pypi2nix/poetry2nix’). Si se necesita ‘conda’ por razones prácticas (paquetes no disponibles en ‘nixpkgs’, flujo de trabajo del equipo), documentar la receta (‘environment.yml’, comando de creación) y versionar el archivo junto al proyecto; idealmente incorporar la creación del entorno ‘’conda’’ en ‘CI’ para asegurar consistencia operativa aunque no absoluta bit-reproducible. ‘Nix’ (por medio de ‘rix’) gestiona ‘git’ y otras dependencias del sistema de forma nativa y declarativa; ‘conda’ puede proveer muchos binarios pero no reemplaza la gestión total de librerías del sistema ni ofrece la misma trazabilidad.
1.4 Pipelines
La gestión de la pipeline es crucial para la eficiencia y la corrección de los análisis complejos. `
(Landau 2021): Esta es la cita oficial y directa del paquete {targets}. Es indispensable. Úsela para introducir la herramienta, explicando que su elección se basa en una solución documentada y revisada por pares diseñada específicamente para crear pipelines de análisis reproducibles y eficientes en R. Resalte características clave que el artículo menciona, como el seguimiento de dependencias y el paralelismo, que son cruciales para análisis a gran escala en conservación.
1.5 Control de versiones
(Noble 2009): Record every operation that you perform. 2. Comment generously. . Avoid editing intermediate files by hand. Use relative pathnames to access other files within the same project. perhaps most significantly, version control is invaluable for collaborative projects. The repository allows collaborators to work simultaneously on a collection of files, including scripts, documentation, or a draft manuscript. If two individuals edit the same file in parallel, then the version control software will automatically merge the two versions and flag lines that were edited by both people.
2 Objetivos
- Integrar datos de ocurrencia de múltiples fuentes (OBIS, GBIF)
- Validar y limpiar coordenadas geográficas usando métodos estandarizados
- Analizar patrones espaciales de distribución de especies marinas
- Modelar idoneidad de hábitat considerando variables ambientales
- Generar recomendaciones para conservación basadas en evidencia
3 Planteamiento del problema
¿Por qué es importante la multiómica? Proporciona una perspectiva más completa de un sistema biológico en lugar de solo estudiar componentes aislados. Sin embargo, es la Integración de datos complejos, los cuales Permiten integrar y analizar grandes volúmenes de datos generados por diferentes tecnologías de alto rendimiento, no suele ser un paso sencillo.
For example, Next-Generation-Sequencing (NGS) bioinformatics uses computational tools, software, and algorithms to process and analyze the massive datasets generated by Next-Generation Sequencing (NGS). It involves cleaning and aligning millions of DNA or RNA fragments to reconstruct genomes or transcriptomes, identifying genetic variants like mutations, and annotating these variants to understand their biological significance. It is essential to consider: Data Processing: Raw sequence reads from NGS instruments are complex and need to be cleaned, aligned to a reference genome, and assembled to form longer sequences. Variant Calling and Annotation: The process identifies genetic variations (such as single nucleotide polymorphisms or structural variations) and adds information about these variants’ potential functions or links to disease. Interpretation and Visualization: The analyzed data is presented in user-friendly formats like reports and visualizations, allowing researchers and clinicians to make informed decisions.
(Dolstra 2006): Software deployment is the problem of managing the distribution of software to end-user machines. That is, a developer has created some piece of software, and this ultimately has to end up on the machines of end-users. After the initial installation of the software, it might need to be upgraded or uninstalled. Presumably, the developer has tested the software and found it to work sufficiently well, so the challenge is to make sure that the software works just as well, i.e., the same, on the end-user machines. I will informally refer to this as correct deployment: given identical inputs, the software should behave the same on an end-user machine as on the developer machine1. This should be a simple problem. For instance, if the software consists of a set of files, then deployment should be a simple matter of copying those to the target machines. In practice, deployment turns out to be much harder. This has a number of causes. These fall into two broad categories: environment issues and manageability issues. Even worse, the component might be dependent on a specific compiler, or on specific compilation options being used for its dependencies. This is often a rather labour-intensive part of the deployment process.
(Dolstra 2006): the Nix deployment system, which overcomes the limitations of contemporary deployment tools described above. It solves implementation (how it works), the underlying principles (why it works), our experiences and empirical validation (that it works), and the application areas to which it can be applied (where it works).
La gestión de la pipeline es crucial para la eficiencia y la corrección de los análisis complejos. {targets} es el estándar moderno en el ecosistema R.
(Landau 2021): Esta es la cita oficial y directa del paquete {targets}. Es indispensable. Úsela para introducir la herramienta, explicando que su elección se basa en una solución documentada y revisada por pares diseñada específicamente para crear pipelines de análisis reproducibles y eficientes en R. Resalte características clave que el artículo menciona, como el seguimiento de dependencias y el paralelismo, que son cruciales para análisis a gran escala en conservación.
(Noble 2009): A few months from now, you may not remember what you were up to when you created a particular set of files, or you may not remember what you drew. You will either have to then spend time reconstructing your previous experiments or lose whatever insights you gained from those experiments.
(Noble 2009): it is important to handle long-running scrips and its outputs. The final line of a runall script calls summarize, which in turn creates a plot, table, or HTML page that summarizes the results of the experiment (in our case, we use quarto for this). The summarize script is written in such a way that it can interpret a partially completed experiment, showing how much of the computation has been performed thus far.
(Boyle et al. 2009): changes in software engineering and design include: the methodology through which software is constructed (e.g. components leading to frameworks, and frameworks leading to aspects [1]); the technology used to allow for distributed computing (e.g. object brokers evolving pass-byvalue mechanisms, and these being replaced by stateless Web Services); and the ideology that is used to define the process through which software is built (e.g. the “rational” processes being replaced by agile programming).
(Noble 2009):In addition, the need to make results accessible to and understandable by wet lab biologists may have practical implications for how a project is managed. For example, to make the results more understandable, significant effort may need to go into the prose descriptions of experiments in the lab notebook, rather than simply including a figure or table with a few lines of text summarizing the major conclusion. More practically, differences in operating systems and software may cause logistical difficulties. For example, computer scientists may prefer to write their documents in the LaTeX typesetting language, whereas biologists may prefer Microsoft Word.
Generación de reportes técnicos con Quarto Scholarly articles require much more detail in their front matter than simply a title and an author. Quarto provides a rich set of YAML metadata keys to describe these details. On this page, you’ll learn how to specify authors and their affiliations, article summaries like an abstract and keywords, and how to include information on copyright, licensing and funding.
Lastly, data integrity, accesibility, and size as it grows requieres more than cvs files in an academic context.
(Boyle et al. 2009): database based solutions to open, distributed, interoperable data management solutions (see Figure 1). This change has been driven by demands for rapid development, high levels of interoperability and increases in data volume and complexity.
4 Metodología
4.1 Crear el ambiente con Nix
El paquete R {rix} ‘r library(rix)’, en línea con este enfoque, permite una integración simplificada de Nix en la plataforma R. Esto significa que las dependencias de R, del sistema y el control de versiones pueden ser gestionados de forma centralizada a través de Nix. La inclusión de {rix} en este proyecto permite el manejo eficiente de las dependencias de R de manera reproducible (Gabay et al., 2019).
En conclusión, la fundamentación del proyecto en la integración de R, Nix y el paquete {rix} se traduce en una robustez y una gestión optimizada de las dependencias, facilitando notablemente el procesamiento y el análisis de datos y el manejo de código. Además, permite la integración eficiente de información en repositorios y proporciona un entorno de trabajo reproducible, lo cual es vital para mantener la validez y la replicabilidad de las investigaciones científicas.
4.2 Automatización de Pipelines con {targets}
La gestión de la pipeline es crucial para la eficiencia y la corrección de los análisis complejos. {targets} es el estándar moderno en el ecosistema R.
4.3 Orquestación del Flujo de Trabajo con Make
El uso de Make como un “orquestador” de alto nivel simplifica la interacción y estandariza los procedimientos.
(Noble 2009): Este influyente artículo describe las mejores prácticas para organizar proyectos de biología computacional. Recomienda explícitamente el uso de Make para automatizar la pipeline, desde la descarga de datos hasta la generación de figuras finales. Citarlo posiciona su uso de Makefile como una práctica establecida y recomendada para mantener la organización, la claridad y la automatización en proyectos complejos, lo cual es vital en estudios integrativos de biodiversidad marina.
4.4 Preparación de librerías
DNA or RNA is fragmented and prepared for sequencing by adding sequencing adapters.
Sequencing: The prepared samples are run on high-throughput sequencing machines to generate millions of short reads.
Primary Analysis: Raw sequence data is converted into FASTQ files, which contain sequence data and quality scores.
Secondary Analysis: Reads are aligned to a reference genome, and variants are identified and annotated.
Tertiary Analysis: The identified variants are interpreted for their potential impact on biological pathways and phenotypes, often by querying genomic databases.
4.4.1 biomatr: Adquisición de Datos ómicos
Se utilizó el paquete ‘r library(biomatr)’, que nos permite obtener datos de organismos de múltiples bases de datos (RefSeq, GenBank, or Ensembl)
Multiple data types: Genome, proteome, CDS, GFF, RNA Availability checking: Check what’s available before downloading Assembly stats: Get quality metrics for assemblies Better error handling: Clear messages about what’s available and what failed.
Implementamos este paquete de tal manera que:
when you run the pipeline:
It will check all databases (refseq, genbank, ensembl) Generate a comprehensive availability report Download all available data Assess data quality Generate a beautiful HTML report with: Species information Database availability tables Success/failure summaries Data size statistics Visual heatmaps Proper citations for all software and data sources The report will be saved as reports/genomic_data_retrieval.html and can be opened in any browser!
4.4.2 Functional annotation
Extract GO terms and protein domains from the successfully retrieved A. palmata data Sequence statistics - Analyze the proteome and CDS sequences
Extract GO terms and protein domains from the successfully retrieved A. palmata data
4.4.3 sequence statistics
Analyze the proteome and CDS sequences
4.4.4 Sequence Analysis
Use the retrieved sequences for comparative genomics Functional Annotation - Extract GO terms and protein domains
4.4.5 Homology Analysis
Find orthologs across species
4.4.6 myTAI: Phylogenetic Analysis
Use for evolutionary transcriptomics
4.5 Adquisición de Datos Ocurrencia
El pipeline integra datos de dos fuentes principales:
- OBIS (Ocean Biodiversity Information System): Base de datos especializada en biodiversidad marina
- GBIF (Global Biodiversity Information Facility): Repositorio global de datos de biodiversidad
4.6 Integration with occurrence data
Link genomic data with the spatial occurrence data you already have
4.6.1 Limpieza y Validación de Datos
Utilizamos el paquete CoordinateCleaner para implementar un protocolo de limpieza comprehensivo:
| Métrica | Porcentaje |
|---|---|
| Completitud de coordenadas | 100.0 |
| Completitud taxonómica | 100.0 |
| Completitud temporal | 100.0 |
| Registros con profundidad | 85.1 |
5 Resultados
5.1 Control del proyecto con Nix
El ambiente (software, dependencias del sistema, librerías, etc.) se controla con el archivo ‘build_env.R’. el cuál facilita la ejecución de distintas tareas controladas por los scripts del directorio ‘scripts/’
5.2 Control de Pipeline con targets
La pipline es controlada con el archivo ‘_targets.R’, el cual controla el flujo utilizando diversas funciones escritas en el direcotio ‘R/’:
- ‘R/data_acquisition.R’: Integrating OBIS, GBIF, biomaRt, wikitaxa, and PRISM for comprehensive data collection.
- ‘R/data_cleaning.R’: Standardizing and validating marine occurrence records from biological collection databases.
- ‘R/data_visualization.R’
- ‘R/database_integration.R’: Efficient storage and querying of heterogeneous marine biodiversity data.
- ‘R/evolutionary_analysis.R’: phylostratigraphic analysis and evolutionary studies in marine organisms.
- ‘R/geospatial_processing.R’: For handling marine occurrence data with spatial coordinates and environmental layers.
- ‘R/metagenomic_analysis.R’
- ‘R/taxonomic_management.R’: standardized handling of marine biodiversity taxonomic information.
5.3 Sujetos Experimentales
Especies analizadas: 3
Registros procesados: 249
Estado del pipeline: completed
Fecha de análisis: 10/10/2025
Species Analyzed
| Species | Common.Name |
|---|---|
| Acropora cervicornis | Staghorn Coral |
| Acropora palmata | Elkhorn Coral |
| Porites astreoides | Mustard Hill Coral |
5.4 Datos disponibles
| Objeto | Disponible | Tipo | |
|---|---|---|---|
| obis_occurrences | obis_occurrences | Sí | data.frame ( 46848 filas) |
| gbif_occurrences | gbif_occurrences | Sí | data.frame ( 0 filas) |
| cleaned_occurrences | cleaned_occurrences | Sí | data.frame ( 249 filas) |
| spatial_analysis | spatial_analysis | Sí | lista ( 4 elementos) |
| habitat_models | habitat_models | Sí | lista ( 3 elementos) |
| data_summaries | data_summaries | Sí | lista ( 4 elementos) |
| pipeline_report | pipeline_report | Sí | lista ( 7 elementos) |
5.4.1 Datos Ómicos
Se encontraron estas especies en las bases de datos
| species | genbank | refseq |
|---|---|---|
| Acropora cervicornis | 5 | 0 |
| Acropora palmata | 3 | 1 |
Detailed Assembly Information
| species | database | organism_name | assembly_accession | bioproject | biosample | seq_rel_date |
|---|---|---|---|---|---|---|
| Acropora palmata | refseq | Acropora palmata | GCF_964030605.1 | PRJNA1278713 | SAMEA114784739 | 2025-04-18 |
| Acropora cervicornis | genbank | Acropora cervicornis | GCA_032359415.1 | PRJNA948411 | SAMN33902175 | 2023-10-04 |
| Acropora cervicornis | genbank | Acropora cervicornis | GCA_037043185.1 | PRJNA473816 | SAMN09283696 | 2024-03-06 |
| Acropora cervicornis | genbank | Acropora cervicornis | GCA_041430625.1 | PRJNA473816 | SAMN35713815 | 2024-08-23 |
| Acropora cervicornis | genbank | Acropora cervicornis | GCA_964034795.1 | PRJEB75258 | SAMEA114784735 | 2024-04-26 |
| Acropora cervicornis | genbank | Acropora cervicornis | GCA_964034985.1 | PRJEB75259 | SAMEA114784735 | 2024-04-28 |
| Acropora palmata | genbank | Acropora palmata | GCA_025960835.2 | PRJNA473816 | SAMN09283722 | 2024-03-07 |
| Acropora palmata | genbank | Acropora palmata | GCA_964030595.3 | PRJEB75080 | SAMEA114784739 | 2025-04-19 |
| Acropora palmata | genbank | Acropora palmata | GCA_964030605.3 | PRJEB75079 | SAMEA114784739 | 2025-04-18 |
5.4.1.1 Resumen por especies y tipo de datos
Data Completeness Visualization
5.4.1.2 Data Size Statistics
| Species | Proteome Size (MB) | CDS Count |
|---|---|---|
| Acropora palmata | 7.48 | 34126 |
5.4.1.3 Successfully Retrieved Data
| species | database | data_type | file_path |
|---|---|---|---|
| Acropora cervicornis | genbank | proteome | Not available |
| Acropora cervicornis | genbank | cds | Not available |
| Acropora cervicornis | genbank | gff | Not available |
| Acropora palmata | refseq | proteome | Acropora_palmata_protein_refseq.faa.gz |
| Acropora palmata | refseq | cds | Acropora_palmata_cds_from_genomic_refseq.fna.gz |
| Acropora palmata | refseq | gff | Acropora_palmata_genomic_refseq.gff.gz |
5.4.1.4 Data Not Found
| species | data_type | reason |
|---|---|---|
| Porites astreoides | All | Species not found in any database |
5.5 Análisis de Datos de Ocurrencia
### Resumen de Datos Limpios
- **Total de registros:** 249
- **Especies únicas:** 3
- **Rango temporal:** 1969 - 2023 | scientificName | Registros | Años únicos | Lat mín | Lat máx | Lon mín | Lon máx |
|---|---|---|---|---|---|---|
| Acropora cervicornis | 35 | 8 | 10.48 | 25.16 | -87.46 | -67.81 |
| Acropora palmata | 49 | 9 | 8.07 | 25.16 | -87.31 | -66.05 |
| Porites astreoides | 165 | 30 | -23.12 | 25.16 | -87.83 | -34.78 |
Summary by Species and Data Type
| species | database | data_completeness | proteome_available | cds_available | gff_available | proteome_size | cds_count |
|---|---|---|---|---|---|---|---|
| Acropora cervicornis | genbank | 100 | TRUE | TRUE | TRUE | NA | NA |
| Acropora palmata | refseq | 100 | TRUE | TRUE | TRUE | 7.48 | 34126 |
| Porites astreoides | NA | 0 | FALSE | FALSE | FALSE | NA | NA |
5.6 Distribución Espacial de Especies
Distribución espacial de registros de ocurrencia por especie
5.7 Análisis de Idoneidad de Hábitat
5.8 Análisis Espacial Comprehensivo
| Métrica | Valor |
|---|---|
| Número de ocurrencias | 249.000 |
| Rango latitudinal (°) | 48.280 |
| Rango longitudinal (°) | 53.050 |
| Centroide latitudinal (°) | 17.386 |
| Centroide longitudinal (°) | -74.477 |
| Área de ocupación (km²) | 408.000 |
| Número de celdas de grilla | 102.000 |
5.9 Nicho Ambiental
*Nota: Las estadísticas ambientales muestran las condiciones preferidas por las especies en sus hábitats naturales.*5.10 Base de Datos Integrada
La base de datos integrada utiliza DuckDB como backend NoSQL, permitiendo:
- Almacenamiento eficiente de datos heterogéneos (ocurrencias, taxonomía, ambiente)
- Consultas flexibles usando sintaxis SQL y JSON
- Exportación múltiple a formatos CSV, JSON, y Parquet
- Escalabilidad para grandes volúmenes de datos
5.10.1 Implicaciones para la Conservación
5.10.1.1 Especies Prioritarias
### Análisis Temporal
**Resumen temporal del dataset:**
- Período: 1969 - 2023
- Años únicos con datos: 30
- Distribución por décadas: 1970s: 12 | 1980s: 3 | 1990s: 115 | 2000s: 91 | 2010s: 18 | 2020s: 8 5.11 Manejo de git
Gracias a la integración de los flujos de trabajo (workflows) de github (controlados por los archivos en el directorio ‘.github/workflows’), se autamitza y simplifica el flujo de trabajo.
The workflows directory contains GitHub Actions workflows that automate tasks when you push your code to GitHub.
Example:
ci.yml (Continuous Integration)
- This file likely defines an automated process that runs whenever you push code or create a pull request.
- Checks that your code builds correctly
- Runs any tests you’ve defined
- Validates that your R packages can be installed
- May check code style/quality
Detalles téxnicos de workflows
What happens when you push to GitHub? Once these files are in your repository:
GitHub automatically recognizes and activates these workflows They’ll run according to their defined triggers (e.g., on push, schedule, etc.) You’ll see workflow runs in the “Actions” tab of your repository The workflows execute on GitHub’s servers You’ll receive notifications if workflows fail Any artifacts or outputs will be stored according to the workflow configuration
5.12 Error handling
(Noble 2009): During the development of a complicated set of experiments, you will introduce errors into your code. Such errors are inevitable, but they are particularly problematic if they are difficult to track down or, worse, if you don’t know about them and hence draw invalid conclusions from your experiment. Here are three suggestions for error handling. Write robust code to detect errors.
Nota
‘direnv: error /home/santi/Projects/NereidaPipeline/.envrc is blocked. Run direnv allow to approve its content’
6 Discusión
La implementación de avanzadas herramientas bioinformáticas y la gestión eficiente de pipelines han revolucionado el estudio de la biodiversidad y la evolución de la biota marina. En este marco, el proyecto propone una aplicación de R que hace uso de Nix por medio del paquete R {rix}, convergiendo en una solución óptima para el manejo de diversas funciones, incluyendo el procesamiento de datos, la gestión de código y la integración de información en repositorios.
Gracias al uso de Nix, un sistema de paquetes de código abierto que adopta una nueva manera de manejar las dependencias, proporcionando un entorno de trabajo coherentemente reproducible. Asegura que los paquetes se construyen e instalan de manera aislada, lo que permite un control de versiones y una gestión de las dependencias finamente afinada (Dolstra, E., 2006). Así, Nix se impone como una herramienta fundamental cambio de contextos académicos y empresariales, permitiendo la creación de entornos de trabajo estables y reproducibles.
6.1 Control de Pipeline Avanzado
6.1.1 Orquestación del Flujo de Trabajo con Make
El uso de Make como un “orquestador” de alto nivel simplifica la interacción y estandariza los procedimientos.
(Noble 2009): Este influyente artículo describe las mejores prácticas para organizar proyectos de biología computacional. Recomienda explícitamente el uso de Make para automatizar la pipeline, desde la descarga de datos hasta la generación de figuras finales. Citarlo posiciona su uso de Makefile como una práctica establecida y recomendada para mantener la organización, la claridad y la automatización en proyectos complejos, lo cual es vital en estudios integrativos de biodiversidad marina.
Makefile
Makefile funciona como un “protocolo de laboratorio” ejecutable. Su propósito principal es automatizar y estandarizar las tareas repetitivas, encapsulando comandos complejos en alias simples y declarativos.
Makefile no es solo un archivo, sino la interfaz de control principal. En lugar de recordar una serie de scripts y sus argumentos, usted y sus colaboradores solo necesitan interactuar con comandos semánticos como make test o make regenerate.
Así es como su Makefile dirige el flujo:
make regenerate: Este es el comando fundamental para la reproducibilidad. No ejecuta rix directamente, sino que delega la tarea al script ./regenerate.sh. Este script, a su vez, invoca su archivo build_env.R, donde la función rix::rix() traduce su lista de paquetes de R y dependencias del sistema en un archivo default.nix. Este es el plano exacto de su ambiente.
make test: Este comando invoca ./test_environment.sh, un paso de validación crucial. El script verifica que el ambiente de Nix, una vez construido, contenga todos los paquetes que su pipeline de {targets} declara necesitar en _targets.R. Esto cierra el círculo, asegurando que el ambiente definido coincide con el ambiente requerido.
make update: Actúa como un meta-comando que ejecuta una secuencia lógica de tareas a través del script update_workflow.sh, probablemente combinando la regeneración y la prueba del ambiente.
make clean: Mantiene la higiene del proyecto, eliminando artefactos y resultados intermedios para garantizar que la próxima ejecución comience desde un estado conocido y limpio.validación crucial. El script verifica que el ambiente de Nix, una vez construido, contenga todos los paquetes que su pipeline de {targets} declara necesitar en _targets.R. Esto cierra el círculo, asegurando que el ambiente definido coincide con el ambiente requerido.
make update: Actúa como un meta-comando que ejecuta una secuencia lógica de tareas a través del script update_workflow.sh, probablemente combinando la regeneración y la prueba del ambiente.
make clean: Mantiene la higiene del proyecto, eliminando artefactos y resultados intermedios para garantizar que la próxima ejecución comience desde un estado conocido y limpio.6.1.2 Control de versiones automatizado con workflows
6.1.2.1 Aggregation subsystem
(Boyle et al. 2009): **aggregation subsystem*: One of the aims of the computing advances over the last few years has involved the concept of run time aggregation. This approach is epitomized by the semantic web, where people can mash information from a variety of data sources into a single graph. When an analysis run has finished, the observing aggregation system can trigger an indexing operation on the results. The indexing is controlled using the properties that are associated with the output of the analysis run (typically the properties related to the rows or columns that are to be indexed).
For this last point… we could try a quarto dashboard to summirize the data and make the github actions trigger to continuously (or at query) deploys updated info to the web.
Nota
Razones clave para preferir Nix + rix en proyectos científicos y pipelines
- Reproducibilidad completa: Nix describe exactamente qué se construye y cuáles binarios y bibliotecas del sistema se usan; rix adapta este enfoque al ecosistema R, permitiendo reconstrucciones idénticas en diferentes máquinas y CI.
- Gestión unificada de R y dependencias del sistema: muchas herramientas R necesitan bibliotecas C/Fortran. Nix las gestiona junto con los paquetes R, evitando fallos invisibles por falta de libs nativas.
- Declaratividad, versionado y trazabilidad: los archivos Nix (o los artefactos que genera rix) son documentos versionables que sirven como metadatos exactos del entorno utilizado para un análisis — esencial para reproducibilidad y revisión académica.
- Aislamiento hermético: elimina efectos de entornos previos o variaciones en el usuario, reduciendo errores “works on machine X”.
- Integración con CI y archivado a largo plazo: cachés binarios y la capacidad de reconstruir entornos permiten validar pipelines en CI y archivar entornos reproducibles junto a publicaciones.
- Interoperabilidad: aunque renv y conda pueden usarse junto a Nix, emplear Nix como capa superior unifica la gestión y reduce la complejidad operativa.
Limitaciones y balance práctico
- Curva de aprendizaje: Nix requiere tiempo para dominar sus conceptos. rix reduce fricción para usuarios R, pero la adopción institucional puede exigir formación.
- Uso de disco y recursos: la store de Nix puede ocupar más espacio, aunque la deduplicación y caché binario compensa en entornos compartidos.
- Windows: Nix funciona mejor en Linux/macOS; en Windows suele requerir WSL o contenedores (esto está mejorando con la comunidad).
Recomendaciones prácticas
- Para investigación reproducible, producción de pipelines y CI: adoptar Nix + rix como estándar de entorno. Mantener la expresión Nix en el repositorio junto con el código y los datos procesables.
- Para desarrollo rápido o enseñanza: combinar renv (para control fino de paquetes R durante el desarrollo) dentro de un entorno Nix que garantice las dependencias del sistema. renv puede convivir con Nix: renv controla versiones R; Nix asegura libs nativas.
- Para entornos multi-lenguaje con uso intensivo de paquetes binarios (Python + R + herramientas C): Nix ofrece la solución más coherente y reproducible frente a la mezcla de conda + gestores del sistema.
6.2 Conservación y Evolucón
6.2.1 Recomendaciones de Manejo
Basándose en los resultados del análisis, se proponen las siguientes estrategias de conservación:
6.2.1.1 1. Protección de Hábitats Críticos
- Establecer áreas marinas protegidas en zonas de alta idoneidad
- Monitorear cambios en las condiciones ambientales clave
- Implementar medidas de mitigación contra el cambio climático
6.2.1.2 2. Monitoreo y Vigilancia
- Desarrollar programas de monitoreo a largo plazo
- Utilizar tecnologías de detección temprana
- Capacitar a comunidades locales en identificación de especies
6.2.1.3 3. Restauración Ecológica
- Identificar áreas históricamente importantes pero actualmente degradadas
- Implementar programas de restauración basados en ciencia
- Evaluar el éxito de las intervenciones de restauración
6.2.1.4 Análisis Evolutivo y Adaptación
### Perspectivas EvolutivasEl análisis filoestratigráfico revela patrones importantes sobre la evolución y adaptación de las especies marinas:- **Genes antiguos** conservados indican funciones esenciales para la supervivencia marina- **Genes de origen reciente** pueden representar adaptaciones específicas al ambiente marino- **Patrones de expresión** durante el desarrollo sugieren estrategias evolutivas de supervivenciaEstas perspectivas son cruciales para:1. **Programas de cría selectiva** para aumentar la resistencia climática2. **Estrategias de restauración** basadas en diversidad genética3. **Predicción de respuestas** a cambios ambientales futuros6.3 Perspectivas y limitaciones
Potential Applications
- Personalized Medicine: Identifying genetic predispositions to diseases and tailoring treatments based on an individual’s genetic makeup.
- Cancer Research: Identifying mutations in tumors to guide cancer treatment strategies and monitor treatment responses.
- Infectious Disease: Tracking outbreaks by sequencing pathogens and understanding their genetic relationships.
- Drug Discovery: Uncovering new drug targets and identifying potential drug repurposing opportunities by understanding disease-causing genetic mechanisms.
Área de Mejora: La principal fricción a futuro es el acoplamiento manual entre _targets.R y build_env.R. Actualmente, si usted añade library(nuevo_paquete) en su pipeline _targets.R, debe recordar manualmente añadir “nuevo_paquete” al vector targets_packages en build_env.R. A medida que el proyecto crezca y colaboren más personas, es casi seguro que este paso se olvidará, lo que provocará fallos en las pruebas (make test) y frustración.
Para que este flujo de trabajo sea verdaderamente a prueba de futuro, el siguiente paso lógico es automatizar la sincronización de paquetes.
Se podría modificar el script regenerate.sh (o crear uno nuevo) para que, antes de ejecutar build_env.R, primero analice el archivo _targets.R en busca de todas las llamadas library(…). Luego, puede pasar esa lista de paquetes como un argumento a su script de R o escribirla en un archivo temporal que build_env.R pueda leer.
Esto desacoplaría completamente la definición del ambiente de la pipeline, adhiriéndose al principio de “Fuente Única de Verdad” (Single Source of Truth). Su pipeline en _targets.R se convierte en la única fuente que define qué paquetes se necesitan, y el resto del sistema reacciona automáticamente.
Sin embargo, la arquitectura actual es excelente, avanzada y se adelanta a la mayoría de los flujos de trabajo académicos. Es altamente reproducible y fácil de usar. Al implementar la sincronización automática de paquetes, lo convertirá en un sistema prácticamente infalible y listo para escalar a cualquier complejidad.
- Sesgos de muestreo: Los datos de ocurrencia pueden estar sesgados hacia áreas de fácil acceso
- Resolución temporal: La variabilidad interanual y estacional no está completamente capturada
- Variables ambientales: Limitadas a las disponibles en bases de datos globales
- Validación de modelos: Se requiere validación independiente con datos de campo
6.3.1 Direcciones Futuras
| Área.de.investigación | Descripción | Prioridad |
|---|---|---|
| Integración de datos genómicos | Incorporar datos de secuenciación para análisis poblacionales | Alta |
| Modelado de cambio climático | Proyectar distribuciones futuras bajo escenarios climáticos | Alta |
| Análisis de conectividad | Analizar flujo genético y dispersión larval | Media |
| Monitoreo en tiempo real | Implementar sensores IoT para datos continuos | Media |
| Inteligencia artificial | Desarrollar modelos de aprendizaje automático avanzados | Baja |
6.4 Conclusiones
El pipeline integrado de análisis de biodiversidad marina ha demostrado ser una herramienta poderosa para:
- Integrar múltiples fuentes de datos de manera eficiente y reproducible
- Validar y limpiar datos usando estándares internacionales
- Generar modelos predictivos de distribución de especies
- Identificar prioridades de conservación basadas en evidencia científica
- Proporcionar insights evolutivos relevantes para la conservación
Los resultados resaltan la importancia de enfoques integrados que combinen datos de ocurrencia, variables ambientales, y análisis evolutivos para informar estrategias efectivas de conservación marina.
✅ Reproducibilidad (Fortaleza Mayor)
Este es el punto más fuerte de su sistema. Al definir el entorno computacional de forma declarativa con rix en build_env.R y materializarlo con Nix, ha eliminado prácticamente la variabilidad del entorno. Cualquier investigador, en cualquier máquina con Nix, puede ejecutar make regenerate y nix-shell para recrear un ambiente de software bit a bit idéntico. Esto es el estándar de oro para la reproducibilidad computacional.
✅ Facilidad de Uso y Mantenimiento (Fortaleza)
El Makefile es la clave aquí. Proporciona una “API” de línea de comandos simple y legible para su proyecto. Un nuevo colaborador no necesita entender los detalles de Nix o los scripts de shell; solo necesita leer la salida de make help para empezar a trabajar. Esto reduce drásticamente la curva de aprendizaje y los posibles errores.
📈 Escalabilidad (Fortaleza con un área de mejora)
Fortaleza: El uso de {targets} es ideal para la escalabilidad del análisis. Su naturaleza basada en dependencias garantiza que solo se recalculen los pasos necesarios, ahorrando un tiempo de cómputo inmenso a medida que el análisis crece en complejidad.Nix, utilizado a través de rix, ofrece la solución más sólida y trazable para garantizar entornos reproducibles y pipelines científicos que integran R con dependencias del sistema. Aunque la adopción exige inversión en aprendizaje, los beneficios en reproducibilidad, integridad y archivado hacen de Nix la opción preferente para proyectos científicos serios y para la producción de análisis reproducibles.
ste trabajo usa una estructura estándar para organización de trabajos bioinformáticos (Noble 2009): top-level organization that is logical, with chronological organization at the next level, and logical organization below that. A sample project, called msms, is shown in Figure 1. At the root of most of my projects, I have a data directory for storing fixed data sets, a results directory for tracking computational experiments peformed on that data, a doc directory with one subdirectory per manuscript, and directories such as src for source code and bin for compiled binaries or scripts.
version control should only be used for files that you edit by hand. Automatically generated files, whether they are compiled programs or the results of a computational experiment, do not belong under version control (Noble 2009).
(Boyle et al. 2009): Layered content management: To manage data arising from ongoing research experiments we adopted an approach using distributed content repositories. Content repositories allow for the development of a formalized structure that can be associated directly with resources. Easy to adapt. Within a research environment it is generally difficult to hammer down requirements. The requirements change over time, and new functionality is often required at short notice. Easy to understand. Any data management solution will involve a high level of complexity, especially in a distributed research environment. Easy to access. Within a research environment there is little time to be spared for learning (largely transient) informatics systems. • Instrumentation Layer. This layer is used to capture experimental information. The layer models information in a way that makes storage of the information simpler, so that laboratory scientists can easily add and annotate information that is captured from a variety of instruments. • Conceptual Layer. This layer is designed to provide a means to generically interact with the information through the use of high level abstract operations. These operations include the aggregation and retrieval of information, and do not necessitate an understanding of the actual information content. • Organizational Layer. This layer provides a project (or researcher) based view on the information, and therefore is designed to have a “biological focus”. Typically the content is organized by factors such as disease, organism or molecule. Each different research, or research group, can individually organize and annotate the data to suit their individual requirements.
6.4.1 Impacto para la Conservación
- Identificación de especies vulnerables con distribuciones restringidas
- Mapeo de hábitats críticos que requieren protección prioritaria
- Desarrollo de estrategias adaptativas para el cambio climático
- Optimización de esfuerzos de monitoreo y recursos limitados
Este enfoque metodológico puede replicarse para otras regiones y grupos taxonómicos, contribuyendo al conocimiento global sobre biodiversidad marina y su conservación.
7 Resumen Ejecutivo
7.1 Estado del pipeline
Código
# Show pipeline status
cat("Estado de los objetos del pipeline:\n\n")Estado de los objetos del pipeline:Código
for (target in names(loaded_targets)) {
status <- if (loaded_targets[[target]]) "✓ Disponible" else "✗ No disponible"
cat("-", target, ":", status, "\n")
}- obis_occurrences : ✓ Disponible
- gbif_occurrences : ✓ Disponible
- cleaned_occurrences : ✓ Disponible
- spatial_analysis : ✓ Disponible
- habitat_models : ✓ Disponible
- data_summaries : ✓ Disponible
- pipeline_report : ✓ Disponible Código
# Check targets status
if (requireNamespace("targets", quietly = TRUE)) {
cat("\nEstado general del pipeline:\n")
tar_progress() |>
count(progress) |>
kable(col.names = c("Estado", "Número de targets"))
}
Estado general del pipeline:| Estado | Número de targets |
|---|---|
| dispatched | 1 |
| skipped | 19 |
7.2 Uso recomendado del ambiente y pipeline
Si se modifica la pipeline
Al modificar el archivo ‘build_env.R’ (p. ej. agregar librerías nuevas), ejecutar este comando:
nix-shell
make updateAl ejecutar este script:
- Regeneramos y construimos el ambiente de Nix
- Ejecutamos el script ‘../test_environment.sh’ para comprobar y verificar la disponibilidad de librerías utilizadas en la pipeline
- Ejecutamos la pipeline (opcional)
Si no se agregan nuevos paquetes a la pipeline
Ejecutar:
nix-shell
make pipeline8 Referencias
Las referencias bibliográficas se incluirían aquí en un análisis completo, citando las fuentes de datos, métodos estadísticos, y literatura científica relevante.
8.1 Software Citations
Please cite the following software packages used in this analysis:
8.1.1 biomartr
Drost HG, Paszkowski J. Biomartr: genomic data retrieval with R. Bioinformatics (2017) 33(8): 1216-1217. doi:10.1093/bioinformatics/btw821
8.1.2 targets
Landau, W. M., (2021). The targets R package: a dynamic Make-like function-oriented pipeline toolkit for reproducibility and high-performance computing. Journal of Open Source Software, 6(57), 2959, https://doi.org/10.21105/joss.02959
8.1.3 Biostrings
Pagès H, Aboyoun P, Gentleman R, DebRoy S (2023). Biostrings: Efficient manipulation of biological strings. R package version 2.68.0, https://bioconductor.org/packages/Biostrings.
8.1.3.1 Data Sources
Data retrieved from the following NCBI databases:
- **NCBI GenBank**: https://www.ncbi.nlm.nih.gov/genbank/
> Sayers EW, et al. Database resources of the National Center for Biotechnology Information. Nucleic Acids Res. 2022;50(D1):D20-D26.
- **NCBI RefSeq**: https://www.ncbi.nlm.nih.gov/refseq/
> O'Leary NA, et al. Reference sequence (RefSeq) database at NCBI: current status, taxonomic expansion, and functional annotation. Nucleic Acids Res. 2016;44(D1):D733-45.8.2 File Locations
All downloaded genomic data files are stored in:
- Proteomes:
data/raw/genomic/proteomes/ - CDS:
data/raw/genomic/cds/ - GFF annotations:
data/raw/genomic/gff/ - Summary reports:
data/processed/genomic/
Report generated on 2025-10-11 14:45:34.281399
8.3 Información de Sesión
Código
sessionInfo()R version 4.5.1 (2025-06-13)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS
Matrix products: default
BLAS/LAPACK: /nix/store/88j7f0rbpihkl11q3q7hb0h7vv8whnz5-blas-3/lib/libblas.so.3; LAPACK version 3.12.0
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
time zone: America/Mexico_City
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] kableExtra_1.4.0 tidyr_1.3.1 leaflet_2.2.2 plotly_4.11.0
[5] ggplot2_3.5.2 DT_0.33 knitr_1.50 dplyr_1.1.4
[9] targets_1.11.3
loaded via a namespace (and not attached):
[1] tidyselect_1.2.1 viridisLite_0.4.2 farver_2.1.2
[4] blob_1.2.4 Biostrings_2.76.0 fastmap_1.2.0
[7] lazyeval_0.2.2 digest_0.6.37 base64url_1.4
[10] lifecycle_1.0.4 secretbase_1.0.5 processx_3.8.6
[13] KEGGREST_1.48.1 terra_1.8-60 RSQLite_2.4.2
[16] magrittr_2.0.3 compiler_4.5.1 sass_0.4.10
[19] rlang_1.1.6 tools_4.5.1 igraph_2.1.4
[22] yaml_2.3.10 data.table_1.17.8 labeling_0.4.3
[25] prettyunits_1.2.0 htmlwidgets_1.6.4 bit_4.6.0
[28] sp_2.2-0 xml2_1.3.8 RColorBrewer_1.1-3
[31] withr_3.0.2 purrr_1.1.0 BiocGenerics_0.54.0
[34] grid_4.5.1 stats4_4.5.1 scales_1.4.0
[37] cli_3.6.5 rmarkdown_2.29 crayon_1.5.3
[40] generics_0.1.4 rstudioapi_0.17.1 httr_1.4.7
[43] DBI_1.2.3 cachem_1.1.0 stringr_1.5.1
[46] AnnotationDbi_1.70.0 XVector_0.48.0 vctrs_0.6.5
[49] jsonlite_2.0.0 callr_3.7.6 IRanges_2.42.0
[52] S4Vectors_0.46.0 bit64_4.6.0-1 systemfonts_1.2.3
[55] crosstalk_1.2.1 jquerylib_0.1.4 glue_1.8.0
[58] codetools_0.2-20 ps_1.9.1 leaflet.providers_2.0.0
[61] stringi_1.8.7 gtable_0.3.6 GenomeInfoDb_1.44.1
[64] raster_3.6-32 UCSC.utils_1.4.0 tibble_3.3.0
[67] pillar_1.11.0 htmltools_0.5.8.1 GenomeInfoDbData_1.2.14
[70] R6_2.6.1 textshaping_1.0.1 evaluate_1.0.4
[73] Biobase_2.68.0 lattice_0.22-7 png_0.1-8
[76] backports_1.5.0 memoise_2.0.1 bslib_0.9.0
[79] Rcpp_1.1.0 svglite_2.2.1 xfun_0.52
[82] pkgconfig_2.0.3 Nota: Este reporte fue generado automáticamente usando el pipeline integrado de análisis de biodiversidad marina. Para más información sobre la metodología y código fuente, consultar el repositorio del proyecto.
Referencias
Boyle, John, Hector Rovira, Chris Cavnor, David Burdick, Sarah Killcoyne, y Ilya Shmulevich. 2009. «Adaptable Data Management for Systems Biology Investigations». BMC Bioinformatics 10 (1): 79. https://doi.org/10.1186/1471-2105-10-79.
Dolstra, Eelco. 2006. The Purely Functional Software Deployment Model. S.l.: s.n.
Landau, William Michael. 2021. «The Targets R Package: A Dynamic Make-Like Function-Oriented Pipeline Toolkit for Reproducibility and High-Performance Computing». Journal of Open Source Software 6 (57): 2959. https://doi.org/10.21105/joss.02959.
Marwick, Ben, Carl Boettiger, y Lincoln Mullen. 2018. «Packaging Data Analytical Work Reproducibly Using R (and Friends)». The American Statistician 72 (1): 80-88. https://doi.org/10.1080/00031305.2017.1375986.
Noble, William Stafford. 2009. «A Quick Guide to Organizing Computational Biology Projects». PLOS Computational Biology 5 (7): e1000424. https://doi.org/10.1371/journal.pcbi.1000424.
Wilson, Greg, Jennifer Bryan, Karen Cranston, Justin Kitzes, Lex Nederbragt, y Tracy K. Teal. 2017. «Good Enough Practices in Scientific Computing». PLOS Computational Biology 13 (6): e1005510. https://doi.org/10.1371/journal.pcbi.1005510.
Reutilización
The code in this repository is licensed under MIT License and the academic quarto report is licensed under CC BY 4.0
(Ver Licencia)
Cómo citar
BibTeX
@online{garcía_ríos,
author = {García Ríos, Santiago},
title = {Análisis de Biodiversidad Marina: Pipeline Integrado para
Conservación y Evolución},
volume = {1},
number = {1},
date = {},
doi = {10.5555/12345678},
langid = {es},
abstract = {Este reporte presenta los resultados del pipeline
integrado de análisis de biodiversidad marina, enfocado en la
conservación y evolución de especies marinas del Caribe. El análisis
incluye datos de ocurrencia de múltiples fuentes, validación de
coordenadas, modelado de idoneidad de hábitat, y análisis espacial
comprehensivo. Combina tres herramientas clave de manera muy
efectiva: Make como orquestador, Nix (a través de rix) como gestor
del ambiente computacional y \{targets\} para la gestión de la
pipeline de análisis. - Biodiversidad - Pipeline}
}
Por favor, cita este trabajo como:
García Ríos, Santiago. n.d. “Análisis de Biodiversidad Marina:
Pipeline Integrado para Conservación y Evolución.” Journal of
Psychoceramics. https://doi.org/10.5555/12345678.